😭 Deploy PR Preview failed.

The browser respecting CORS headers does indeed not apply to forms. But the server-side checks that are done by the CORS filter do prevent CSRF also for forms. Therefore it's "only" this part of the filter that is relevant for CSRF, setting the headers does not play a role.

But the server-side checks that are done by the CORS filter do prevent CSRF also for forms

How?

By checking whether Origin either matches Host or is part of a whitelist, similar to https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#using-standard-headers-to-verify-origin

I guess it depends on whether CORS will reject requests when no Origin and Referer are present, is it the case?

CSRF is mostly only an issue in the browser because it automatically sends session cookies with every requests. And the browser always sets the Origin header. Requests without Origin usually come from other applications, such as curl (in the very simple case). There CSRF is not issue because there is no cookie in the first place.

The browser respecting CORS headers does indeed not apply to forms. But the server-side checks that are done by the CORS filter do prevent CSRF also for forms.

@sithmein If form submissions are done from scripts, sure CORS filter will handle it, but HTML forms that are just part of simple HTML pages won't have Origin set if the page's origin is different, right ? So indeed as @FroMage recommends, we can highlight that the the proposed advice applies to XHR/Fetch only...

It's hard to find definite information but as far as I know, the Origin header is also set for cross-origin form requests. However, in such cases it's set to null instead of the real origin. But this doesn't interfere with the filter because null will hardly ever be an allowed origin.
See also https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Origin

@sithmein

It's hard to find definite information but as far as I know, the Origin header is also set for cross-origin form requests. However, in such cases it's set to null instead of the real origin. But this doesn't interfere with the filter because null will hardly ever be an allowed origin.

Sure.

Let me suggest a couple of other minor updates to stress the users have to be certain that Origin is indeed set in all cross-origin cases

@sithmein Have a look at the proposed updates please, I suppose we indeed should offer a rather strong recommendation for users to check it, to make sure users do not incidentally deploy the CORS filter where no Origin is available for whatever reasons

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit a68d147.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.